A. Field of the Invention
The present invention relates generally to a multicast communication in a connection-oriented (e.g., asynchronous transfer mode (ATM)) network, and more particularly to adaptable multicast data communication services.
B. Description of the Related Art
Conventional multicast communication services that distribute data to several receiving parties in an ATM network allow the sending party to send the data to all receiving parties by setting up a point-multipoint ATM connection from the sending party to all receiving parties. When the sending party simply sends data to the point-multipoint connection without copying the data for each receiving party, the data are simply transmitted to all the receiving parties. In this context, the sending/receiving party could be an actual source/destination host, or could be a connection-less packet relaying node, such as a router.
Conventionally, service attributes, such as bandwidth or quality of service (QoS), that are provided by this point-to-multipoint connection are the same for all receiving parties. This restriction, however, may give rise to certain problems.
For example, sometimes the service attributes requested by the receiving parties are different. One party may request a reliable guarantee of fixed bandwidth, even though it may involve some degree of communication cost, while another receiving party requests low cost communication without any guarantee of QoS. One method of handling these different requests is to set up a point to multipoint connection to all receiving parties with the same service attributes satisfying the requests of the most demanding receiving party.
However, this method requires guaranteeing the prescribed resource end-to-end in the network even for a receiving party who has not requested such a QoS guarantee. Such a guarantee is undesirable both from the point of view of efficient utilization of network resources and from the point of view of providing low cost communications.
Another method for implementing ATM multicast communication when the requested service attributes differ depending on the receiving party is to divide the receiving parties into groups. The receiving parties belonging to each group are the ones whose requested service attributes are the same (or similar). Then, point-to-multipoint connections can be set up for each group separately. In the extreme case, however, this method can result in the sending party setting up the same number of point-to-point connections as the number of receiving parties.
The problems with this method are that the sending party must copy data as many times as the number of connections set up, depending on the attributes to output the data to each connection, and that bandwidth in the portion of the network close to the sending party (the sending-side user network interface) is wasted.
Another problem with providing point-to-multipoint connection of the same service attributes for all receiving parties is that it may not be possible to reserve bandwidth within the network for some of the receiving parties. Trying to add a new "leaf" with a certain service attribute to a point-to-multipoint connection for a new receiving party results in denying the leaf-adding request if sufficient bandwidth cannot be reserved to satisfy the service attribute on the path to the receiving party. This means the new receiving party will be unable to receive any data if sufficient bandwidth to satisfy the service attribute is not available anywhere on the path to the new receiving party.
Even in this case, the receiving party can receive data if the sending party sets up another connection to the receiving party with a different service attribute (e.g., a service with no QoS guarantee). However, the processing burden will still remain on the sending party for copying data, and bandwidth will be wasted in the portion of the network close to the sending party.